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(54) Secure software distribution system and software utilization scheme 



(57) A software distribution system and a software 
utilization sclieme for effectively preventing an illegal 
copy of a software is difficult while improving a conven- 
ience of a user. At a user side, a shared key to be 
shared between a software provider and a user is 
stored, where the shared key has a guaranteed corre- 
spondence with an ID Information regarding a payment 
of a software fee by the user. Then, a desired software 



is requested to the software provider, and the desired 
software is received in an encrypted form from the soft- 
ware provider. The desired software received from the 
software provider is then deaypted by using the shared 
key stored at the user side, and the desired software In 
a decrypted form is utilized at the user side. 
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Description 

BACKGROUND OF THE INVENTION 

FIELD OF THE INVENTION 5 

The present invention relates to a system for distrib- 
uting software products and a scheme for utilizing dis- 
tributed softare products. 

10 

DESCRIPTION OF THE BACKGROUND ART 

Due to the spread of computers and computer net- 
works, It is now possit>le to realize the software distribu- 
tion entirely electronically, without utilizing the is 
conventional trade system based on cash payment. 

The major problem in the software distribution now 
is how to specify a person who is trying to acquire the 
software and charge this person safely at a time of dis- 
tributing the software that can be rather easily copied. so 

Conventionally, a charging mechanism on the com- 
puter network has utilized the authentication technique 
based on the cryptography. For example, in a case of 
notifying a credit card number on the computer network, 
it has been necessary to encrypt the credit card number ss 
and transfer the encrypted credit card number so that a 
third person cannot obtain the credit card number ille- 
gally by wiretapping the communication line. 

On the other hand, a scheme for preventing an ille- 
gal copy has also been developed. The most frequently 30 
employed scheme is to apply some encryption to the 
software so that only a person who has a key (a cipher 
key a password, etc.) for decrypting encrypted data can 
obtain the actual content of the software. However, in 
this scheme, it is still possible to make an illegal copy of 35 
the software by illegally copying the key or password 
itself. 

As it has been quite difficult to resolve all these 
problems completely by means of the software alone, 
there has been a proposition of a system called super- 40 
distribution which presumes a use of some special 
hardware. Namely, this is a system which uses a hard- 
ware functioning a black box that outputs some output 
data in response to an entered input data, while a con- 
tent of this hardware itself cannot be analyzed even by 45 
the owner of this hardware. For example, it is possible to 
realize a scheme in which the encrypted data cannot be 
decrypted unless this function of a black box is availa- 
ble, by means of the conventional cryptographic tech- 
nique such as the public key cryptosystem. so 

However, this scheme is not very practical because 
it is necessary for every customer to have his own ded- 
icated hardware and utilize this hardware all the times. 
In addition, even if this scheme is employed, it is not 
going to be able to prevent the illegal copy completely ss 
For instance, even if only a particular person can replay 
the music provided by the software, it is still possible to 
copy that music by recording that music itself using 
some recording device. Because of these limitations. 



the super-distribution system has not been widely 
accepted commercially 

Fig. 1 shows a conventional scheme for safely 
sending a credit card number on the network by utilizing 
the cryptographic technique. 

In Fig. 1. the left side represents a store which is 
offering the software for sale and the right side repre- 
sents a ci^tomer who is trying to purchase the soft- 
ware. These store and customer are connected by a 
computer network (which will be abbreviated hereafter 
as a network) such as a telephone line or Internet. Note 
here that functions on the store side and functions on 
the customer side are basically to be realized by means 
of softwares. 

The store has a store secret key 101 and a store 
public key 102 according to the public key cryptosystem 
in advance. The store secret key 101 is stored in a store 
secret key storage unit 350. and its content cannot be 
referred from the others. The store public key is publicly 
disclosed so that anyone can acquire it through the net- 
work. 

When the customer purchases the software, the 
customer first generates a shared key 103 at a shared 
key generation unit 302 in order to establish a safe com- 
munication with the store. This is done by generating a 
random number whdh cannot be guessed by the oth- 
ers. This shared key 103 is also referred to as a session 
key as it is shared during a particular session. The gen- 
erated shared key 103 is then encrypted by a shared 
key encryption unit 312. The store public key 102 is uti- 
lized for this encryption. 

The shared key enayption unit 312 gives this 
encrypted shared key 104 to a shared key transmission 
unit 314, and then the shared key transmission unit 314 
transmits this encrytted shared key 1 04 to the store side 
tiirough the network. At the store side, a shared key 
decryption unit 352 receives this encrypted shared key 
104. and descrypts it using the store secret key 101 so 
as to obtain the shared key 103. 

On the other hand, at the customer side, an infor- 
mation encryption unit 316 encrypts an information to 
be transmitted to the store side, by using the shared key 
103. For instance, this information encryption unit 316 is 
utilized in encrypting a credit card number to be trans- 
mitted to the store side. The encrypted information 107 
obtained by the information encryption unit 316 is then 
transmitted to the store side tiirough the network by an 
information transmission unit 318. At the store skSe, an 
information decryption unit 354 receives the encrypted 
information 107 and descrypts it by using the shared 
key 1 03 so as to obtain tiie information transmitted from 
the customer side. 

According to this procedure, an information such as 
a credit card number can be transmitted safely tiirough 
the network. Namely the shared key 103 encrypted by 
using the store public key 102 can be decrypted only by 
tiie store who has the store secret key 1 01 according to 
tiie principle of tiie public key cryptosystem. Moreover, 
tiie transmitted Information can only be descrypted by 
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the store and the customer who shared the shared key 
103 in this manner. 

By the above described scheme, rt is possible to 
sell the software only to a legitimate user who actually 
notified a necessary information such as a credit card s 
number. However, the software can be copied easily in 
general, so that it is difficult to prevent an illegal act of 
copying the purchased software and distributing or sell- 
ing the copied software. 

There are many propositions for preventing such an 
illegal act. such as a scheme for making the software 
operable only upon an entry of a specific password or a 
scheme for making the software executable only upon 
an acquisition of a license from a specific server at a 
time of each execution, rather than selling the software 
as it is, but none of them has proven to be definitive. The 
reason Is that it is still possible to make an illegal copy of 
the purchased software by copying not just the software 
itself alone but alt surrounding portions of the customer 
side system (software) that are necessary in utilizing 
the software as well so as to reproduce the identical 
software utilization environment elsewhere, and there- 
fore it is possible to commit this illegal act without any 
serious risk. 

On the other hand, in a case of using a system 
which requires a complicated procedure such as an 
entry of a credit card number of a customer or a user ID 
or a password assigned to that customer in every occa- 
sion of the purchase, it is practically impossible to real- 
ize an elaborated charging scheme such as that for 
charging three yen for the tomorrow's weather forecast 
(as a low value service will be disused when a proce- 
dure is complicated). As a consequence, only expen- 
sive softwares could be distributed successfully and 
some software right owners could profit enormously 
while some other software right owners could not profit 
at all, so that the proper growth of the software distribu- 
tion cannot be expected. 

Even when a mechanism for storing a credit card 
number in a computer and automatically transmitting 
the stored credit card number is used in order to resolve 
this situation, for example, there is a possibility for the 
illegal use of that computer by a tiiird person when tiiat 
computer is stolen, so that the convenience and the 
safety cannot be achieved simultaneously. 

As described, in the conventional software distribu- 
tion system, it is possible to make a purchase order 
electronically without a danger of having a credit card 
number stolen, but a measure against tiie illegal copy of 
the purchased software has been insufficient. This is 
because a process of ordering tiie software and a proc- 
ess ofutilizing the software have been separate proc- 
esses from a customer's viewpoint, and it has been 
possible to apply various illegal methods for realizing 
the illegal copy to tiie software once tiie software was 
purchased. 

In addition, in some conventional software distribu- 
tion system, it has been difficult to establish an elabo- 
rated charging scheme such as that for charging the 



same customer repeatedly when this customer utilizes 
tiie same software at different conputers. for example. 

Nowadays, due to the rapid spread of the Internet, 
a system for electronically distributing information such 
as programs and charging for tiie distributed information 
is widely in use. 

The major requirements in realizing the software 
distribution through a network such as tiie Internet 
include: (1) a mechanism for specifying a person who is 
trying to acquire tiie software and charging this person 
safely (a high security measure); (2) a protection of tiie 
copyright of the software in view of the fact that the soft- 
ware can be rather easily copied (a prevention of illegal 
copy); and a measure against a spread of the software 
containing virus. 

Of tiiese. (1) and (2) are already discussed above. 
As for (3), tills is an indispensable requirement because 
tiie information such as programs is to be exchanged 
through the network. 

In addition, it is also necessary to consider an effec- 
tive utilization of communication resources by account- 
ing for the communication line cost, etc.. in view of the 
fact that a large amount of information is to be transmit- 
ted through tiie network. 

From a point of view of the user's convenience, 
operations such as those for downloading programs 
tiirough tiie network and installing tiiem into a user's 
own terminal can be too difficult especially for those 
who are not accustomed to handle a personal compu- 
ter. In order to realize a wide spread of such a system, it 
is expected to be required tiiat even a person witiiout 
much knowledge about tiie personal computer, tiie 
communication, etc. must be able to operate a system 
easily. 

Moreover, in a case of selling the electi'onic infor- 
mation through the network, it is also necessary to pro- 
vide a measure for handling a user's dissatisfaction wrtii 
the purchased software product, because it is impossi- 
ble to actually return the purchased software product 
ttself even when a user is dissatisfied with tiie purposed 
software product. 

Furthermore, it is desirable for such a system to be 
able to deal witii tiie version updating of tiie software 
tiirough the network easily, as it contributes to increase 
a user's reliability on a sales agent and a user's enthu- 
siasm for purchasing the software product, thereby real- 
izing a wide spread of a system. 

Thus tiie conventional software distrit)ution system 
has been associated witii problems tiiat not enough 
considerations have been given to the illegal copy of tiie 
software and the user's convenience. 

SUMMARY OF THE INVENTION 

It is tiierefore an object of tiie present invention to 
provide a software distribution system and a software 
utilization scheme in which an illegal copy of a software 
is difficult. 

It is another object of tiie present invention to pro- 
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vide a software distribution system and a software utlti- 
zation scheme in which a user can purchase a software 
through a network by means of a simple operation. 

It is another object of the present Invention to pro- 
vide a software distribution system and a software utili- s 
zation scheme for enabling a safe software distribution 
at proper prices. 

It is another object of the present invention to pro- 
vide a software distribution system in which the system 
operation can be done easily and the user's conven- 
ience can be improved by omitting required user opera- 
tions for a purchase request and an install of a software 
offered through the networK and for a frequently 
required software version updating procedure. 

It is another object of the present invention to pro- 
vide a software distribution system in which the user's 
convenience can be improved by offering a free sample 
version (an active function part) of the software to be 
purchased first, and offering a passive function part for 
realizing functions of the regular software product at an 
appropriate price if the user is satisfied with the soft- 
ware product through a trial use of the free sample ver- 
sion. 

It is another object of the present Invention to pro- 
vide a software distribution system in which a charged 
part (a passive function part) of the software Is stored at 
the user's terminal in an encrypted form after being 
downloaded, and It Is necessary to use an ID uniquely 
assigned to the user's terminal at a time of decrypting 
the encrypted software part, so as to be able to deal 
with the illegal copy of the software. 

It Is another object of the present invention to pro- 
vide a software distribution system with a high security 
level, In which a charging processing is carried out at a 
time of offering a charged part (a passive function part) 
of the software to the user, according to a pre-reglstered 
user's charge information, so that there is no need to 
transmit a highly classified Information on a credit card 
number at every occasion to purchase the software. 

According to one aspect of the present invention 
there Is provided a method for utilizing a software, com- 
prising the steps of: storing a shared key shared 
between a software provider and a user, the shared key 
having a guaranteed correspondence with an ID infor- 
mation regarding a payment of a software fee by the 
user; requesting a desired software from the user to the 
software provider, and receiving the desired software In 
an encrypted form from the software provider; deaypt- 
ing the desired software received from the software pro- 
vider by using the shared key stored at the storing step; 
and utilizing the desired software In a decrypted form. 

According to anoth©- aspect of the present Inven- 
tion there is provided a software distribution system in 
which a desired software is provided In an encrypted 
form from a software provider to a user, comprising: 
shared key storage unrts provided at both a software 
provider side and a user side, for storing a shared key 
shared between the software provider and the user, the 
shared key having a guaranteed correspondence with 



an ID information regarding a payment of a software fee 
by the user; a request transmission unit provided at the 
user side, for transmitting a request for the desired soft- 
ware to the software provider side; a software encryp- 
tion unit provided at the software provider side, for 
encrypting the desired software by using the shared key 
stored in the shared key storage unit on the software 
provider side; an encrypted software transmission unit 
provided at the software provider side, for transmitting 
the desired software in an encrypted form to the user 
side; and a software decryption unit provided at the user 
side, for receiving the desired software in an encrypted 
form from the software provider, decrypting the desired 
software received from the software provider by using 
the shared key stored in the shared key storage unit on 
tiie user side, so as to obtain the desired software in a 
decrypted form that can be utilized at the user side. 

According to another aspect of the present Inven- 
tion there Is provided a software distribution system In 
which a desired software Is provided from a software 
provider to a user through a networK comprising: a cli- 
ent terminal on a user side, which Is connected with a 
server on a software provider side through the network, 
and Including: a registration unit for registering a user 
charging information and a shared key shared between 
the software provider and the user into the server; a 
request unit for sending a request for a desired software 
to the server; and an install unit for Installing each soft- 
ware downloaded from tiie server In response to tiie 
request sent by tiie request unit; and a server on tiie 
software provider side. Including: a charging processing 
unit for can-ying out a charging processing according to 
tiie user charging information registered by the registra- 
tion unit, when the desired software requested by tiie 
request is a fee charged software; and a download unit 
for downloading a software in response to the request 
sent by the request unit, the software to be downloaded 
being encrypted by using the shared key registered by 
the registration unit when the software to be down- 
loaded is required to be enaypted. 

Otiier features and advantages of the present 
invention will become apparent from the following 
description taken In conjunction with tiie accompanying 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Rg. 1 is a diagram for explaining a conventional 
scheme for safety sending a credit card number on a 
network. 

Rg. 2 Is a block diagram of a software disfribution 
system according to the first embodiment of the present 
Invention. 

Rg. 3 Is a block diagram of a partial configuration of 
tiie software distribution system of Fig. 2 in a modified 
case of the first embodiment of tiie present invention. 

Fig. 4 is a diagram showing an exemplary data 
structure in a user information storage unit of the soft- 
ware distribution system of Fig. 2. 
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Rg. 5 is a block diagram of a partial configuration of 
the software distribution system of Fig. 2 in an applica- 
tion case of the first embodiment of the present inven- 
tion. 

Rg. 6 is a block diagram of a software distribution s 
system according to the second embodiment of the 
present invention. 

Fig. 7 is a data flow diagram showing an exemplary 
flow of key data used in the software distribution system 
of Fig. 6. '0 

Fig. 8 is a data flow diagram showing an exemplary 
flow of data at a time of user registration in the software 
distribution system of Fig. 6. 

Fig. 9 is a diagram showing an exemplary data 
structure in a personal information file storage unit of is 
the software distribution system of Fig. 6. 

Fig. 10 is a data flow diagram showing an exem- 
plary flow of data at a time of downloading a software 
product in the software distribution system of Fig. 6. 

Fig. 11 is a diagram showing a conceptual configu- 20 
ration of a software product in the second embodiment 
of tiie present invention. 

Fig. 12 is a block diagram of a partial configuration 
of the software distribution systOT of Fig. 6 for explain- 
ing a function of a core software used in the second 25 
embodiment of tiie present invention. 

Fig. 1 3 is a flow diagram for a processing procedure 
at a time of downloading a software in tiie software dis- 
tribution system of Fig. 6. 

Fig. 14 is a diagram showing an exemplary data 30 
configuration for an install list used In the second 
embodiment of tiie present invention. 

Fig. 15 is a diagram showing an install command 
format used in the second embodiment of the present 
invention. 35 

Fig. 16 is a diagram showing an exemplary install 
command in tiie install command format of Fig. 15. 

Fig. 1 7 is a diagram showing an exemplary data for- 
mat for downloading a requested file In the second 
embodiment of tiie present invention. <o 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

Now. several embodiments of a software utilization 45 
scheme and a software dist'ibution system according to 
the present invention will be described in detail. 

First, intended meanings of some terms used in the 
following description will be defined. 

In tiie following, a software should be understood to so 
cover everytiiing that can be electronically transmitted 
witiiout a physical distribution, including computer pro- 
grams, databases, results obtained by the information 
retrieval service, books, musics, movies, TV programs, 
games, information to be interactively exchanged by tiie ss 
telephone or the Interactive TV, etc. 

Also, in the following, an ID information related to a 
software fee payment shouki be understood to include a 
credit card number, a valid period of a credit card, a pri- 



vate authentication number, a bank account number, a 
membership number related to a payment which is 
issued by a specific company (such as a user ID of a 
personal computer communication), etc. 

Also, in the following, an auxiliary information 
related to a software utilization should be understood to 
mean an information on auxiliary conditions or software 
utilization environment at a time of a software utilization, 
which includes a number unique to a computer owned 
by a user (host ID), a producrt number of an OS in use, 
a password which is known only by a user, data regis- 
tered In an IC card owned by a user, output data of an 
IC card owned by a user which is obtained upon entry of 
some input data, a time indicated by a built-in clock 
inside a computer, etc. 

Refemng now to Fig. 2 to Fig. 5, the first embodi- 
ment of a software utilization scheme and a software 
distribution system according to tiie present Invention 
will be described in detail. 

A mechanism for tiie software distribution is based 
on tiie cryptography technique, and the point is how to 
construct a safe system by utilizing tiie cryptography 
technique. Here, the data encryption algoritiim itself can 
be tiie known one and tiiere are many known algo- 
rithms, so that tiieir detailed description will be omitted 
here. 

For tiie purpose of data encryption, it is sufficient if 
a seaet key necessary for the encryption is generated 
prior to the encryption and this secret key is shared by a 
user and a correspondent, but tiiis cannot be assumed 
in a general case of software distribution, so that it is 
necessary to exchange tiie key first To this end. tiie 
public key cryptosystem can be used. 

In the public key cryptosystem, a store which sells 
softwares has two keys called a public key and a seaet 
key. Data to be transfen-ed is encrypted by using tiie 
public key at a fransmitting SKle, and decrypted by using 
the secret key at a receiving side. The public key is liter- 
ally a key to be disclosed in public, so that anyone can 
see the public key. A customer is requested to encrypt a 
shared key (not to be confused with the secret key) by 
using tiiis public key, and send tiie encrypted shared 
key to the store. The store which has tiie secret key can 
decrypts the encrypted shared key by using the secret 
key. so as to obtain the shared key. In this scheme, even 
when communication data is wiretapped by a third per- 
son, tiiis third person cannot decrypt the communica- 
tion data because this third person does not know tiie 
secret key. 

The well known example of the public key crypsto- 
system Is the RSA scheme. There are also some proto- 
cols combining various cryptography technkjues such 
as STT (Secure Transaction Technology) and SEPP 
(Secure Electronic Payment Protocol) for tiie electronic 
payment in which information on a aedit card number 
can be transfenred to the credit card company witiiout 
disclosing the credit card number even to the store. 
These protocols are devised in consideration to the 
security among three parties: a customer, a store, and a 
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credit card company. In contrast, the present invention 
is directed to an Improvement of exchanges between a 
customer and a store In particular. In this first embodi- 
ment, this latter aspect of the present Invention will be 
described in detail, but it is also possible to apply the 5 
present invention to exchanges among three parties, by 
combining appropriate techniques. 

Fig. 2 shows a typical configuration of a software 
distribution system in this first embodiment. In Fig. 2, 
the left side represents a store which sells a software, 10 
while the right side represents a customer who pur- 
chases the software, and the store and the customer 
are connected through a network. 

Here, the charging Is to be made by specifying a 
person who is trying to acquire that software, and charg- is 
Ing this person by using this person's bank account, this 
person's credit card account, or electronic money. The 
system must be so constructed that various illegal acts 
can be prevented at this point. For example, it is neces- 
sary to prevent an illegal deceiving of the fee, an lllugal 20 
means for acquiring the software, an illegal use of the 
other person's account to acquire the software illegally, 
an illegal act of making some other person purchases 
the software against that other person's will, an Illegal 
act of claiming later on that the software was not pur- 25 
chased despite of the fact that software was indeed pur- 
chased, an illegal act of acquiring the other person's 
account number by wiretapping data transmitted 
through the computer network, etc. 

The prevention of Illegal copy is also an Important 30 
issue. Even when a perfect charging mechanism Is 
devised, the software can be copied rather easily in 
general, so that It is easily possible to distribute the pur- 
chased software to the others for free, or illegally resell 
the purchased software at cheaper price. In particular, 35 
in the today's well developed computer networK It Is 
possible to carry out such Illegal acts completely 
secretly by using information exchange means such as 
an encrypted electronic mail or message board, so that 
this is a very important Issue today. 40 

As shown in Fig. 2, the store has a store secret key 
101 and a store public key 102 according to the public 
key cryptosystem. The store secret key 101 is stored In 
a store secret key storage unit 50, and its content can- 
not be referred from the others. The store public key 1 02 4S 
is publicly disclosed so that anyone can acquire it 
through the network. As a mechanism for acquiring the 
public key, a conventional scheme using a key distrifcxj- 
tion center is known, so that its description will be omit- 
ted here. so 

In this first embodiment, the overall operation Is 
divided into three stages of a user registeration section, 
an order section, and a utilization section. The user reg- 
istration section is an operation for showing that a cus- 
tomer has a credibility such as a credit card solvency, ss 
The order section Is an operation for actually making an 
order. The utilization section is an operation for utilizing 
the purchased software. Here, It is assume that a cus- 
tomer who has done the user registration once can 
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make the order without the user registration from the 
next time. 

Note here that it is possible to modify these opera- 
tions of this first embodiment In such a trivial manner 
tiiat the user registration section and the order section 
are carried out together and called an order section, for 
example. In the following, these three stages of the 
operation in this first embodiment will be desaibed for 
the most general case. 

When a customer wishes to purchase the software, 
a shared key 103 is generated by a shared key genera- 
tion unit 2 on the customer side in order to establish a 
safe communication with the store. This is done by gen- 
erating a random number that cannot be guessed by the 
others. In the conventional software distribution system, 
the shared key was used only at a time of the order and 
the purchase, and discarded after the use without stor- 
ing it in anywhere. In contrast, in this first embodiment, 
the shared key 103 is encrypted at a shared key encryp- 
tion unit (B) 20 on the customer side, and a resulting 
encrypted shared key 202 is stored In a shared key stor- 
age unit 22 on the customer side. 

At the shared key encryption unit (B) 20, an auxil- 
iary information 203 obtained by an auxiliary Informa- 
tion detection unit 8 on the customer side is used as an 
encryption key at a time of encryption. 

By using the auxiliary information 203 for the 
encryption of the shared key 103 at the shared key 
encryption unit (B) 20, the lowering of the safety due to 
the stealing of the shared key storage unit 22 can be 
prevented. 

In addition, by selecting which auxiliary information 
Is to be used, it becomes possible to realize the charing 
In a variety of different manners. For example, the 
charging can be made such that the software can be 
used continuously as long as the same machine is 
used, or the charging can be made such that the soft- 
ware cannot be used even on the same machine when 
a new OS is used, unless tiie fee is paid again. Also, tiie 
charging can be made such that there is a need to pay 
another fee when a certain time (date) is reached, or tiie 
charging can be made such that the software can be 
used for free during tiie night time but the software use 
during tiie day time Is limited. 

Moreover, It is also possible to use the password 
entered by the user at that point as the auxiliary infor- 
mation. In such a case, by modifying tiie setting of tiie 
auxiliary Information detection unit 8. It Is easily possible 
to limit the software utilization to only a person who 
knows tiie specific password. 

Note that tiiere is an option of not providing tiie 
shared key encryption unit (B) 20 and the auxiliary infor- 
mation detection unit 8. In such a case, the shared key 
103 generated by the shared key generation unit 2 will 
be directiy stored into the shared key storage unit 22. 

Now. tiie shared key 103 generated in tiiis manner 
is also encrypted by a shared key encryption unit (A) 1 2 
on the customer side. At a time of this enayption, tiie 
store public key 102 is utilized. The shared key encryp- 
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tion unit (A) 12 sends a resulting encrypted shared key 
104 to a shared key transmission unit 14, and the 
shared key transmission unit 14 transmits this 
encrypted shared key 104 to the store side through the 
network. A shared key decryption unit (B) 52 on the 5 
store side then then decrypts this shared key 104 by 
using the store secret key 101, so as to obtain the 
shared key 103. 

Also, an ID generation unit 4 on the customer side 
generates an ID 201 Ibr the store to distinguish this cus- 10 
tomer from the other customers. This ID 201 can be 
basically an arbitrary random number, but the subse- 
quent processing can be complicated if the ID 201 over- 
taps with the ID created by the other customer, so that 
the ID 201 should be created by a manner for avioding is 
the overlap as much as possible. For example, the ID 
201 can be given as a combination of a creation time 
and an ID of a connputer owned by the customer. The ID 
201 is sent to a registration request encryption unit 16 
whie being stored into an ID storage unit 24 at the same 20 
time. Here, the storing of the ID 201 may be made by 
encrypting the ID 201 and then storing the encrypted ID. 
by using the simitar procedure as in a case of storing the 
shared key 103, but it is assumed tiiat tiie ID 201 is to 
be stored without encryption in the following. 25 

On the other hand, the customer carries out a user 
information input at a user information input unit 6. 
Here, the user information includes a crediting informa- 
tion, an address, a name, an age. a name of tiie soft- 
ware desired to be purchased (in a case of making an so 
order at tiie same time as the registration), etc. 

Here, the crediting information is an information for 
showing that this customer certainly has an ability to 
pay. and that tiiis customer can be responsible for tiie 
order. For example, tiie crediting information can be a 35 
credit card number, a valid period of a credit card, a pri- 
vate authentication number, etc. Also, depending on a 
manner of payment, the crediting information can be a 
bank account number, a membership number related to 
a payment which is issued by a specific company (such 40 
as a user ID of a personal computer communication), 
etc. In the fbllowtng, the credit card number is used as a 
representative example of such a crediting information 
for the sake of simplicity. 

Now, a user information 105 so erttered is sent to 45 
the registration request encryption unit 16. This registra- 
tion request encryption unit 16 encrypts the received ID 
201 and user information 105 by using the shared key 
103 to obtain an encrypted registration request 204. 
The encrypted registration request 204 is then transmit- so 
ted by a registration request transmission unit 18 to a 
registration request decryption unit 54 on tiie store side 
through tiie network. 

The registration request decryption unit 54 decrypts 
the encrypted registi-ation request 204 by using ttie ss 
shared key 1 03. so as to obtain the user information 1 05 
and the ID 201. After it is confirmed ttiat this ID 201 is 
not overlapping witii any ID used for tiie otiier customer 
in the past, this ID 201 is accepted as tiie formal ID. If 



tills ID 201 is overlapping, tiie above described proce- 
dure is repeated from the beginning once again. Here, a 
method for confirming the ID and repeating the proce- 
dure is already known in the art and sinple so tiiat its 
description will be omitted. 

Then, tiie registration request decryption unit 54 
sends a customer information 108 to a customer infor- 
mation confirming unit 56. Here, the customer informa- 
tion is a part of the decrypted user information 105 
which is related to the payment. For example, thecus- 
tomer information 108 can be a credit card number and 
a name. Also, tiie customer information confirming unit 
56 confirms the credibility of tiie customer by inquirying 
(a system of) a customer credit investigation organiza- 
tion for credit cards, for example. 

Note tiiat. in the description up to tiiis point, tiie 
communication from the customer to the store is carried 
out by encrypting the ID 201 and the user information 
105 by using tiie shared key 103. but this part of the 
above description can be modified. For example, Rg. 3 
shows a partial configuration which differs from the cor- 
resporxiing one in Fig. 2, in an exemplary modified case 
of sending all of the ID 201, the user information 105 
and tiie shared key 103 by encrypting them using tiie 
store public key 102. In this case, the shared key 103 
generated by the shared key generation unit 2. the ID 
201 generated by the ID generation unit 4, and tiie user 
information 105 obtained by tiie user information input 
unit 6 are all sent to the registration request encryption 
unit 16*. Then, the registration request encryption unit 
16' encryptes them by using the store public key 103, 
and sends the resulting encryption registration request 
204' to ttie registration request transmission unit 18'. 
The encrypted registration request 204' fransmitted by 
tiie registration request transmission unit 18' is received 
by tiie registration request decryption unit 54' and 
decrypted by using tiie store secret key 101 so as to 
obtain tiie user information 105, the ID 201 and the 
shared key 103. The rest of tiie operation in this case of 
Fig. 3 is identical to the operation in a case of Fig. 2. 

Now, on tiie store side, a user information storage 
unit 58 stores in correspondence the user information 
105, tiie ID 201 and the shared key 103 obtained from 
tiie registration request decryption unit 54, when tiiis 
customer is a good user to whom tiie software can be 
sold from now on according to a credit information 110 
confirmed by the customer information confirming unit 
56. 

Rg. 4 shows an exemplary data structure to be 
stored in the user information storage unit 58. In Fig. 4, 
the information of each customer is managed in the reg- 
istration order. Here, tiiere is no need to manage tiie 
information in the registration order, but in a case of 
attaching a time information to tiie ID generated by tiie 
ID generation unit 4 for tiie purpose of avoiding tiie 
overlap of IDs, the ID overlap check can be carried out 
for only IDs of those customers who are registered 
rather recently. 

As shown in Fig. 4, for each customer, tiie user infr- 
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mation storage unit 58 records an ID, a shared key, a 
credit card number, and a private information. Here, the 
ID is a number uniquely assigned to that customer, 
which is used at a time of extracting the shared key or 
the credit card number of that customer. The shared key 5 
has the same function as already explained. 

The credit card number is a number used in the 
payment by that customer. This credit card number nnay 
contain the valid period of the credit card within itself. In 
a case of using the payment from the bank account, a to 
bank account number or a user specific number for 
specifying a bank account number will be entered 
Instead. 

Also, the credit card number Is data to be sent by 
the store to the credit card company in order to specify is 
the customer name, so that it Is not absolutely neces- 
sary to register the card number Itself. For example, a 
customer number issued by the credit card company for 
the purpose of notif lying the customer name to the store 
may be stored instead. In such a case, there Is no need 20 
for the store to manage the customer's credit card 
number, so that the safety against the stealing of the 
user Information storage unit 58 can be increased. In 
this regard, the Improvement can be realized by a 
method the conventionally known In the electronic pay- 2s 
ment protocol, so that its description will be omitted. 

The private information is an auxiliary information 
related to that customer, which may not necessarily be 
significant for the payment purpose. However, the pri- 
vate information recorded here may be utilized as a ref- 30 
erence data for the purpose of the credit investigation 
for that customer. 

In Fig. 4, for the fourth customer in the registration 
order, the information in fields other tiian tiie ID Is 
erased. This Implies tiiat tiie sales with respect to tills 35 
customer had been stopped for some reason. The rea- 
son for keeping tiie ID even after the sales had been 
stopped is because the subsequent processing would 
be complicated if an order is made by that customer 
after tiie same ID is newly registered for another cus- 40 
tomer. Here, however, this customer actually cannot 
make an order illegally because the shared key does 
not match, so that an entire entry for tiiis customer may 
be erased after a certain period of time. 

Also, In Fig. 4, for tiie f Iftii custmer in the registration 45 
order, the information in the credit card number field 
alone Is erased. This Implies that a valid period of a 
credit card of this customer has expired. In this case, 
however, the shared key is still valid, so that it implies 
that tiie store still acknowledges tiie legitimacy of this so 
customer. By registering a new credit card number, it 
becomes possible for this customer to make an order 
again. Thereafter, the software sales witii respect to the 
customers are carried out according to the user Infor- 
mation 105 and the ID 201 stored In this user informa- ss 
tion storage unit 58. 

Note that, in Fig. 4, each data Is depicted In a non- 
encrypted form lor the sake of simplicity, but it Is prefer- 
able to store each data In an encrypted form in the 



actual system for the sake of security against the steal- 
ing. For example, ttie encrypted shared key can be 
stored instead of storing the shared key. This can be 
readily realized by the conventionally known technique 
so tiiat Its description will be omitted. 

This completes tiie description of the user registra- 
tion section in this first embodiment. 

Next, tiie order section for actually making an order 
in this first embodiment will be described. 

At the customer side, the customer enters a product 
specifying data 106 such as a name of the software 
desired to be purchased at a software specifying unit 
10. The product specifying data 106 is tiien sent to a 
hash unit 28 and a request transmission unit 26, while 
tiie ID 201 extracted from tiie ID storage unit 24 Is also 
sent to the hash unit 28 and the request transmission 
unit 26. On the other hand, a shared key decryption unit 
(A) 30 decrypts tiie encrypted shared key 202 taken 
from ttie shared key storage unit 22 by using the auxil- 
iary information 203 detected by tiie auxiliary informa- 
tion detection 8. so as to obtain the shared key 103. 

Tiie hash unit 28 hashes the product specifying 
data 106 and the ID 201 by using the shared key 103, 
and sends tiie obtained hash value 205 to tiie request 
ta'ansmisslon unit 26. Here, the hashing Is an operation 
to obtain a certain value (hash value) by applying a spe- 
cific function (which Is shared at tiie store side) with 
respect to an input data, where tiiis function has a prop- 
erty that ttie output cannot be guessed from the input 
and is usually refen-ed to as a hash function. A metiiod 
for producing tiie hash function is conventionally known 
so tiiat Its description wilt be omitt^. 

The request transmission unit 26 transmits the 
product specifying data 106. tiie ID 201 and the hash 
value 205 to the store side. A request receiving unit 60 
at the store side tiien receives tiiese data, and reads out 
tiie shared key 103 of the customer who has ttie cone- 
spending ID from the user information storage unit 58. 
When tiie corresponding ID cannot be found, it is 
regarded as an error and an order will not be accepted. 

A hash unit 62 on tiie store side hashes tiie product 
specifying data 106 and the ID 201 by using tiie shared 
key 103 so as to obtain a server hash value 205' and 
sends this server hash value 205* to a request Inspec- 
tion unit 64. The request inspection unit 64 tiien com- 
pares tills server hash value 205' with the hash value 
205 received from tiie request receiving unit 60. Tiie 
function of the hash unit 62 is Identical to ttie hash unit 
28 on tiie customer side, so that tiie has value 205 and 
tiie server hash value 205' should coincide. If tiiey do 
not coincide, it Implies that eitiier it is an order from a 
user who does not have tiie correct shared key or It Is an 
improper order such as that in which a name of tiie 
product ordered by tiie other person has been altered. 
Note ttiat, as will be desaibed below, even If the soft- 
ware is sold wittiout tills check, a person who does not 
have the shared key cannot utilize tills software anyway, 
but this check Is still necessary because there can be a 
person who makes an Improper order using tiie other 
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person's name for the purpose of harassing that other 
person. 

When the hash value 205 and the server hash 
value 205' coincide, the request inspection unit 64 noti- 
fies this fact to a software transmission command unit s 
66. At this point, an occun-ence of the purchase request 
(order) from the customer is legitimately proved, and the 
payment can be made. As for a specific manner of the 
payment, it suffices to use a method known in the con- 
ventional electronic payment, so that it description will 
be omitted. 

Note that, strictly speaking, tiiere can be a case in 
which the request transmission metiiod described here 
is insufficient. For example, by wiretapping the commu- 
nication and repeatedly transmitting the same request 
to the store, a person who does not have the shared key 
can make an improper order. This is an illegal act usu- 
ally known as a replay attack, and it is known that this 
replay attack can be avoided by attaching an order time 
information or a serial number issued by the store to the 
request. Such cryptographic techniques can be 
enployed in the present invention, but tiiey are conven- 
tionally known so tiiat tiieir description will be omitted. 

The software transmission command unit 66 sends 
the shared key 1 03 to a software encryption unit 70, and 
commands tiie transmission of the encrypted software 
to an encrypted software transmission unit 72. The soft- 
ware encryption unit 70 encrypts a conresponding soft- 
ware 113 read out from a software storage unit 68 by 
using the shared key 103 to obtain an encrypted soft- 
ware 114, and the encrypted software transmission unit 
72 transmits the encrypted software 114 to the cus- 
tomer side. 

Here, the encryption of the software is used for tiie 
purpose of casting tiie software into a form which can- 
not be directiy executed or refen-ed. so that there is no 
need to carry out tiie usual data encryption. For exam- 
ple, a computer program which has a mechanism of 
being not executable unless the password is entered 
can be considered as a kind of the encrypted software. 
In the following description, tiie encrypted software is 
assumed to have this broad meaning unless othenMse 
stated. The encrypted software 114 transmitted from 
the store side is tiien stored into an encrypted software 
storage unit 32 at the customer side. 

This completes the description of the order section 
in this first embodiment. 

Next, tiie utilization section for actually utilizing the 
software in this first embodiment will be described. 

First, the shared key decryption unit (A) 30 on the 
customer side decrypts the encrypted shared key 202 
taken out from tiie shared key storage unit 22 by using 
the auxiliary information 203 detected by the auxiliary 
information detection unit 8 so as to obtain tiie shared 
key 103. The operation up to this point is based on tiie 
same mechanism as that for taking out the shared key 
at a time of making an order. A software decryption unit 
34 tiien decrypts tiie encrypted software 114 taken out 
from tiie encrypted software storage unit 32 by using 
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the shared key 103 so as to obtain tiie software 113. 

By tiie above described procedure, it is possible to 
sell the software only to the legitimate user who actually 
notified necessary information such as a credit card 
number. In addition, tiie shared key 103 is stored in an 
encrypted form obtained by using the auxiliary informa- 
tion 203, so that even when all of the shared key deayp- 
tion unit (A) 30, ttie shared key storage unit 22 and tiie 
encrypted software storage unit 32 are copied, it is 
impossible to make an illegal copy of the software. 
Moreover, it is also difficult to make an illegal copy of tiie 
software by analyzing the operation mechanism of the 
software, so tiiat it actually becomes pointless to make 
an illegal copy by spending much effort and time. 

Furthermore, unlike tiie conventional software dis- 
ti'ibution system in which no damage is incun'ed to a 
person who distributes illegal copies so that there was 
no effective way of preventing this illegal act, according 
to the software distribution system of tiiis first embodi- 
ment, tiie shared key 103 on which ttie encryption is 
based is a key for use In the execution of the software as 
well as a key for use in the purchase of the software, so 
tiiat if a malicious user distributes illegal copies with his 
shared key set therein to tiie otiiers, tiie otiiers could 
tiien purchase new softwares by using that malicious 
user's credit card number so that there is a possibility of 
incurring an actual damage to a malicious user himself, 
and for this reason it is quite effective in preventing tiiis 
type of illegal act. 

Also, the software disti-ibution system of this first 
embodiment adopts a scheme in which a user who has 
completed the user registration once can subsequentiy 
purchase softwares without being required to enter tiie 
aedit card number as long as a user uses the same 
computer used for the user registration, which Is con- 
veni&it for a user, and yet at tiie same time, the charg- 
ing can be made quite safely. In addition, in ttie software 
disti-ibution system of this first embodiment, there is no 
need for a customer to have a uniquely assigned public 
key In otiier words, the sales can be realized under a 
relatively loose condition that a customer is assumed to 
have his own credit card number. 

Also, as an application of the first embodiment, it is 
possible to apply tiiis software utilization scheme only to 
a part of the software, rather tiian the software in its 
entirety. For example. Rg. 5 shows a partial configura- 
tion for realizing such an application case of the first 
embodiment, where a core software unit 35 of Fig. 5 is 
a program corresponding to tiie software decryption unit 
34 of Fig. 2. 

This core software unit 35 is the main portion of tiie 
computer program which cannot be operated com- 
pletely in tiiis form. Further functions can be added to 
tills main portion by adding ttie encrypted software to 
this core software unit 35. In other words, even when 
tiie encrypted software is executed by a person who has 
no right to decrypt this encrypted software, not all ttie 
functions of the software can be realized. 

When the core software unit 35 is executed, a soft- 



EP0 795 809 A2 



15 



20 



25 



30 



35 



40 



45 



50 



9 



17 



EP0795 809A2 



18 



ware decryption unit 351 checks whether the encrypted 
software corresponding to this core software unit 35 
exists in the encrypted software storage unit 32 or not. If 
it exits, the corresponding encrypted software 114 Is 
read out from the encrypted software storage unit 32, s 
decrypted by using the shared key 103. and a resulting 
decrypted software 301 is stored into a decrypted soft- 
ware loading unit 353. If the shared key 103 cannot be 
obtained, connect data cannot be stored into the 
decrypted software loading unit 353. 

The core software unit 35 verifies that the 
decrypted software 301 stored in the decrypted soft- 
ware loading unit 353 is the connect data. Here, a 
method for realizing this verification can be a method for 
checking whether the decrypted software 301 stored in 
the deaypted software loading unit 353 is identical to 
data anticipated by the core software or not (I.e., 
whether It is correctly decrypted or not), or a method tor 
executing the decrypted software 301 stored in the 
decrypted software loading unit 353 Itself as a program, 
for example. 

The advantages of this application case of the first 
embodiment are as follows. 

First, it is possible to set the core software portion 
as a limited function version of the software and only a 
charged portion of the software can be sold as the 
encrypted software. For example, the core software can 
be a word-processor without a printing function and a 
communication function, and the printing function and 
the communication function are to be sold as separate 
charged softwares. Using this scheme, the core soft- 
ware can be distritxjted for free through a freely acces- 
sible medium such as a CD-ROM or an electronic 
message board from which the core software can be 
acquired by anyone, and the charged portion can be 
purchased only when a user is satisfied witii a trial use 
of tiie core software. 

In tiie conventional mail order sales, there is a sys- 
tem for protecting a customer called a cooling off period 
during which a customer can return the purchased 
product for free of charge because the product cannot 
be checked in advance, but in a case of dealing witii the 
software which is in an intangible form, it is impossible 
to return the once purchased software. In this regard, it 
Is possible to protect the customer by offering the core 
software shown in Fig. 5 as a sample version for trial 
use by the consumer, without a need for any cooling off 
period. After tiie actual tibial use, the customer can pur- 
chase the other charged functions only when the cus- 
tomer is satisfied witii tiie trial use. In addition, instead 
of providing one free portion and one charged portion, It 
Is possible to offer more than one additional functions, 
so that the customer can purchase only tiie desired 
additional functions at appropriate price. In this manner, 
it is also possible to prevent an unfair trade practice to 
require the customer to purchase everytiiing including 
those functions which are actually unnecessary for that 
customer. 

Also, an amount of data involved in tiie encryption 



and decryption can be reduced in tills application case. 
In general, the calculation for the encryption or decryp- 
tion takes a time in proportion to an amount of data 
Involved, so tiiat If a software in a very large size is sold 
by encrypting it one by one at a time of purchase. It 
would require a considerable amount of time for the pur- 
chase (downloading) and/or the execution (decryption). 
For this reason, a portion to be encrypted should be 
kept as small as possible. 

This requirement can be satisfied automatically by 
simply dividing a portion to be encrypted and a portion 
not to be encrypted if an amount of data for tiie charged 
additional function portion is very small. However, when 
the charged additional function portion Is large or when 
tiie entire software is a charged one to be encrypted, 
tiie mechanism shown In Fig. 5 can be utilized by setting 
the core software such tiiat tiie charged portion cannot 
function unless tiie encrypted software is decrypted 
even if the encrypted software itself is stored in the core 
software unit. 

Also, the reduction of an amount of data implies 
that the communication line can be a thin one. In other 
words, the downloading takes time in general when a 
communication line between tiie store and the customer 
for purchasing the charged Information is slow, but If the 
core software portion was already distributed by a CD- 
ROM or acquired through tiie oUier high speed network. 
It suffices to acquire a small encrypted software portion 
alone, so tiiat ttie purchase does not take much time. 

Moreover, tiiis application case can also be utilized 
as anotiier method for preventing the illegal copy. For 
example, when the software to be sold is In a form of a 
book, the software wilt be eventually converted into tiie 
character string data In a computer readable format on 
a memory, so tiiat it Is possible to steal such converted 
data from a memory rather easily. In such a case, the 
core software can be set as a software for reading the 
book, which reads the indivkiual software (book) offered 
as a charged additional function and displays a content 
of the Individual software on a screen. Then, by adopt- 
ing a mechanism in which the core software decrypts 
and displays the necessary data (encrypted data) 
whenever a need arises, it becomes quite difficult to 
read out all tiie book data (characters) together. 

In addition, tiie decrypted software is going to be 
present on a memory only while tiie core software is 
executed, so that when a procedure for the core soft- 
ware to utilize tiie encrypted software is made very tedi- 
ous, it is possible to improve the safety because It would 
require a considerable amount of effort and time to 
break tiie encryption of tiie software. In general, a soft- 
ware to be sold through a network is often a software 
which requires rather frequent version updating or an 
Information witii only a temporal value (such as a 
weather forecast information), so that when the safety 
level of the software is made very high, it becomes 
much more economical to purchase the software legiti- 
mately by paying the proper price rather than spending 
much effort and time to produce illegal copies of tiie 
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software. Consequently, when the safety level is made 
very high, it becomes pointless to commit the illegal act, 
and the fair distribution of the software wilt be promoted. 

Note that, in the above description, it is assumed 
that the software is to be sold at some price, but the 
application of the present invention Is not limited to such 
a case of selling the software at some price. For exam- 
ple, in a case of distributing a software whose export to 
a certain country is prohibited, the software distribution 
system of this first embodiment can be utilized in distrib- 
uting such a software to specific customers alone 
according to the user information. 

It should also be obvious that a mechanism for 
charging a utilization fee for each occasion to utiize the 
software can be readily realized by a simple modifica- 
tion of the first embodiment described above to add the 
function of the order section to the core software unit of 
Fig. 5. 

It is also possible to realize the software distribution 
system of this first embodiment in a form of a software 
itself, by Implementing the required procedures in forms 
of programs on a computer. 

Now, the major effects obtained by the software dis- 
tribution system of this first embodiment will be summa- 
rized. 

In this first embodiment, at a time of purchasing the 
software, the software can be purchased in a manner 
convenient to the customer in which there is no need to 
spend effort and time in entering the aedit card number, 
while the charging can be realized safely. Also, what is 
to be charged can be specified in a sophisticated man- 
ner, so that the sales at a price appropriate for a value 
of each software will be promoted. 

The consumer can create the shared key for ena- 
bling the purchase at a desired store at his own will by 
using the general purpose credit card, so that there is 
no need to memorize the membership number issued 
by each store, and the software can be purchased while 
keeping the credrt card itself in safety. In addition, even 
if the shared key is stolen, the use of the shared key is 
quite limited so that the damage Is kept minimum. This 
shared key has a lower generality than the usual credit 
card so that the potential damage is very low even if it Is 
stolen. Moreover, there is no need to pay any money in 
advance unlike a case of using a prepaid card, and the 
user can create or discard the shared key according to 
the need at his own wilt. 

Moreover, the shared key is a key for use in the exe- 
cution of the software as well as a key for use in the pur- 
chase of the software, so that h Is both difficult as well 
as risky to make the illegal copy of the software, and 
consequently it becomes pointless to commit the illegal 
act so that the protection of the copyright owner's right 
can be realized easily. 

Note that one of the purposes of the present inven- 
tion is to enable the install of the software without a tedi- 
ous procedure. However, when a mechanism for 
realizing an easy install is provided, it also becomes 
easier to rewrite data of the individual customer such as 



program files, and there is a possibility of creating a 
security hall in which a malicious person steals the com- 
munication and offers false programs to the customer 
from a faked store. However, according to the software 

5 distribution system of this first embodiment, the soft- 
ware is provided in an encrypted form obtained by using 
the shared key which are only known to the store and 
the customer, so that even if a malicious person suc- 
cessfully offers the false programs to the customer ille- 

10 Qally. the customer can easily detect this illegal act 
because the malignant false program data cannot be 
correctly decrypted by using the shared key. Thus, a 
malignant conputer program called a virus which 
causes some harmful effects will not be installed 

15 according to this first embodiment, so that the safety of 
the software distribution can be improved. 

According to the software distribution system of this 
first embodiment, a shared key to be used when a soft- 
ware provider offers the encrypted software to a user is 

20 set in relation to the ID information related to the pay- 
ment of the software fee, and a user who shares the 
shared key is not required to enter the ID information at 
every occasion of ordering the software, so that the soft- 
ware can be purchased through the network by a simple 

25 operation, while the software provider can realize the 
software distribution at a proper price safely. Moreover, 
the illegal copy of the software can actually incur dam- 
age to a malicious user, so that the Illegal copy of the 
software can be prevented effectively. 

30 Referring now to Fig. 6 to Fig. 17, the second 
embodiment of a software distribution system according 
to the present invention will be described in detail. Fig. 6 
shows an overall configuration of a software distribution 
system in this second emtxxjiment. which generally 

35 comprises a server 401 for selling softwares and a client 
terminal 402 for purchasing softwares, which are con- 
nected through a network such as the Internet. 

The software distribution system of Fig. 6 is a sys- 
tem for electronically distributing softwares to a user 

40 safely and conveniently, and charging fees for the dis- 
tributed softwares. Namely, a user makes an access to 
the server 401 through the network using a browser (not 
shown) of the client terminal 402. for example, and 
transmits a purchase request for a desired software. At 

45 the server 401, the requested software is downloaded 
into ^e client terminal 402 while charging the user at 
the same time. At the user side, it is possible to pur- 
chase and install a desired software by simply manipu- 
lating a mouse (not shown) of the own terminal (client 

50 terminal). 

Now. a user who wishes to use the software disitri- 
bution system of Rg. 6 first activates a registration soft- 
ware at the own clierrt terminal 402 (a personal 
computer, for instance). 

55 The registration software is a software for carrying 
out a prescribed system setting and a user registration 
to the sender 401 . 

The registration asoftware is stored in a registration 
software storage unit 422 of the server 401 in advance. 
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and downloaded and immediately installed Into the cli- 
ent terminal 402 through the networ by a registration 
software download function unit 41 1 . 

A registration software function unit 431 of the client 
terminal 402 is a function unit which is set into an exe- 
cutable state at the client terminal 402 as the registra- 
tion software downloaded from the server 401 is 
installed into the client terminal 402, and which exe- 
cutes functions of the registration software. 

Note that the registration software may be distrib- 
uted to the user in advance by means of a recording 
medium such as a CD-ROM. 

When the registration software function unit 431 is 
activated, the presalbed system setting is carried out 
first. 

Next, the user registration to the server 401 is car- 
ried out. Namely, the registration software function unit 
431 first generates a session key and a shared key for 
encryption and decryption of a high security level infor- 
mation (a credit card number, an authentication infor- 
mation, etc.) to be transmitted between the sender 401 
and the client terminal 402. applies a prescribed 
encryption processing to the generated shared key, and 
stores the encrypted shared key in an information file 

434. 

In addition, according to a procedure displayed at 
the client terminal 402, the user enters a personal infor- 
mation such as a name, an address, a credit card 
number, a valid period of a credit card, an age, a date of 
birth, etc.. and this personal information is encrypted by 
using an encryption key which is predetermined 
between the server 401 and the client terminal 402 and 
transmitted to the sender 401 through the network. 

At a registration software admission function unit 
412 of the server 401, when the encrypted personal 
information and the key data are received, a decryption 
using a prescribed decryption key is carried out and a 
credibility inquiry with respect to a credit card company 
is carried out through a credibility inquiry unit 413. 
When the credibility is confirmed, the personal informa- 
tion and the key data are registered into a personal 
information file storage unit 424 through a database 
registration unit 414. (If the personal information and the 
key data are already written, they are updated to new 
data while a back-up of old data is made.) 

When the user registration is finished normally and 
a notice about this fact is received, the client terminal 
402 installs a program to be activated at a time of soft- 
ware purchase by the user, that is, a download program 
435. Namely, the download program 435 is already 
downloaded along with the registration software, and 
this download program 435 is outputted from the regis- 
tration software function unit 431 and installed into the 
client terminal 402. 

A download program function unit 432 of the client 
terminal 402 is a function unit which is set into an exe- 
cutable state at the client terminal 402 as the download 
program downloaded from the server 401 Is installed 
into the client terminal 402, and which executes func- 



tions of the download program. 

When the registration software function unit 431 
installs the download program, a setting for automati- 
cally activating the download program is made. This set- 

5 ting is made, for example, by registering a command for 
activating the download program when a prescribed 
identification information (which is assumed to be "Con- 
tent-type: Application/ABC in this second embodiment) 
is detected from a header portion of data received at the 

10 client terminal 402 into a prescribed file. 

This completes the user registration using functions 
provided in the registration software. 

Next, the operation of each function unit in the soft- 
ware distribution system at a time of downloading a 

15 desired software from the server 401 wilt be described. 
Rrst, the user activates the browser of the client ter- 
minal 402, for example, and makes an access to the 
server 401 by manipulating the mouse and requests a 
desired software to the server 401 . 

20 At an Install list transmissfon function unit 415 of the 
server 401 which received this transmission request, an 
install list (a list describing which file should be installed 
how) corresponding to the software specified by the 
user is read out from an install list storage unit 425 and 

25 transmitted to the client terminal 402. 

When the install list is received, the client terminal 
402 activates the download program function unit 432 
and transmits a request (download request) selected 
according to the install list to the server 401 . 

30 At a download program admission function unit 416 
of the server 401 , a file is read out from one of a core 
software storage unit 426, a passive function file stor- 
age unit 427 and a library storage unit 428 according to 
the request from the client terminal 402, and when it is 

35 confirmed that this user is an already registered user by 
referring to the personal information stored in the per- 
sonal information file storage unit 424. the read out file 
is transmitted to the client terminal 402. At this point, the 
data compression (and the data encryption if neces- 

40 sary) is can-ied out. Also, when the file requested from 
the client terminal 402 is a file to be charged, a pre- 
scribed charging processing is carried out by referring 
to the personal infornr^tion stored in the personal infor- 
mation file storage unit 424. 

45 The download program currently executed at the 
client terminal 402 then receives the file from the server 
401 . and if there is no error, this file is installed. 

A core software f unctfon unit 433 of the client termi- 
nal 402 is a function unit which is set into an executable 

so state at the client terminal 402 as the software down- 
loaded from the server 401 is installed into the client ter- 
minal 402. and which realizes prescribed information 
processing functions. This core software function unit 
433 is configured such that a pre-installed core software 

55 436 becomes fully functional as a passive function file 
37 is incorporated by the core software 436 at a time of 
its activation. 

Note that a program to be downloaded can be a 
general program other than the core software and the 
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passive function file, and such a general program will be 
downloaded from the server 401 as a library 438. 

An installed information storage unit 501 of the cli- 
ent terminal 402 registers an information (file names 
and version information) regarding files constituting the 
core software 436 and the passive function file 437 
which are downloaded from the server 401 and installed 
into the client terminal 402. 

Note that, as will be described below, a software 
product is formed by an active function file and a pas- 
sive function file, where the passive function file is 
encrypted and then downloaded from the server 401, 
and stored into the client terminal 402 in the enaypted 
form. 

When the core software furrction unit 433 is acti- 
vated, the installed information storage unit 501 is 
searched through to check whether the passive function 
file is already installed or not. When the related passive 
function file is already installed, this encrypted passive 
function file is decrypted, and the normal operation is 
executed by incorporating the decrypted passive func- 
tion file. 

Next, with reference to Fig. 7, an exemplary flow of 
the key data used in the software distribution system of 
Fig. 6 will be desQ-ibed. Here, an exemplary flow of data 
at a time of user registration as shown in Fig. 8 will also 
be referred whenever necessary. 

A random number generation unit 451 provided in 
the registration software function unit 431 generates a 
random number as a shared key 461 to be shared 
between the server 401 and the client terminal 402. 

This shared key 461 is a key to be used for prevent- 
ing the illegal copy of the software. This shared key 461 
is encrypted by the seaet key cryptosystem such as 
DES (Data Encryption Standard) for example, using a 
product ID uniquely assigned to each client terminal 
402 and then stored as a key file 452 in the information 
file 434 of the client terminal 402. 

Also, when a setting of a password 462 at the client 
terminal 402 is possible, this password 462 is hashed by 
using the shared key 461 and the obtained output is 
used as a purchase key 463. Here, the purchase key 
463 Is a key to be used for the user authentication at a 
time of product (software) purchase. Here, if a password 
is not available, the shared key 461 itself can be directly 
used as the purchase key 463. 

The random number generation unit 451 generates 
a session key 464 and a shared key 461 at the client ter- 
minal 402 at a time of the user registration. 

The session key 464 is a key to be used at a time of 
encrypting the personal information and the key data 
(the shared key 461. the purchase key 463) by the 
secret key cryptosystem such as DES for example, at a 
time of the user registration. At this point, the session 
key 464 is also encrypted by the public key ayptosys- 
tem such as RSA (Rivest Shamir Adieman) using a pub- 
lic key 465 which is prescribed with respect to the 
software provider and included in the registration soft- 
ware, and then transmitted to the server 401 . 



The encrypted personal information, key data (the 
shared key 461 , the purchase key 463) and session key 
464 transmitted from the client terminal 402 are 
received at the server 401. the encrypted session key 

5 464 is decrypted by the RSA first, and the encrypted 
personal information and key data are decrypted by tiie 
DES using the decrypted session key 464. The session 
key 464 is then discarded. 

At tiie server 401, tiie decrypted personal irrfbrma- 

10 tion and key data are stored into the personal informa- 
tion file storage unit 424. while the credibility inquiry 
according to tiie personal information Is carried out, as 
indicated in Fig. 8. 

Note that, at a time of the credibility inquiry, a re- 

15 confirmation witii respect to the client terminal 402 may 
also be made via another route, according to the need. 

Rg. 9 shows an exemplary data structure of tiie 
personal information to be stored in the personal infor- 
mation file storage unit 424. As shown in Rg. 9. for each 

20 customer, the personal information file storage unit 424 
records in correspondence the key data (tiie shared key, 
the purchase key) fransmitted from ttie client terminal 
402. and tiie personal information including a credit 
card number and a private information such as a name 

25 and an address, and this information for users are 
recorded in an order of user registration. 

The information stored in the personal information 
file storage unit 424 will be referred in tiie user autiienti- 
cation, the credibility inquiry witii respect to the credit 

30 card company, and the charging processing for the soft- 
ware when each registered user purchases tiie soft- 
ware product. 

Rg. 10 shows an exemplary flow of the key data 
used in tiie software disti'ibution system of Fig. 6 and an 

35 exemplary flow of data at a time of downloading the soft- 
ware product from tiie server 401 . 

In the software product to be downloaded from tiie 
server 1 to ttie client terminal 402. the core software is 
not encrypted and immediately installed at same time 

40 as the downloading into the client terminal 402 as 
already described. 

On tiie other hand, at a time of downloading the 
passive function file, tiie server 401 first carries out pre- 
scribed user authentication processing and charging 

45 processing witii respect to a user who made the trans- 
mission request for tiiat software, and encrypts tiie 
specified passive function file by using tiie shared key 
461 of tiiat user, and tiien downloads tiie encrypted 
passive function file to the client terminal 402. 

so When the encrypted passive function file is 
received at the client terminal 402. the encrypted pas- 
sive function file is stored into a prescribed region (an 
encrypted software storage unit 441 shown in Fig. 12) in 
the encrypted form. 

55 When the core software is activated, the core soft- 
ware first decrypts tiie encrypted shared key 461 stored 
in tiie key file 452 by using the product ID 467. and 
decrypts the encrypted passive function file by using the 
decrypted shared key 461. and then incorporates tiie 



13 



25 



EP0795 809A2 



26 



decrypted passive function file into itself. 

Now. the features of the software product to be 
downloaded in the software distribution system of this 
second embodiment will be described with reference to 
Fig. 11. 5 

Fig. 1 1 shows a conceptual configuration of the 
software product in this second embodiment. As shown 
in Fig. 1 1 , the software product generally comprises the 
core software (active function file) 436 and the passive 
function file 437. 

The core software 436 is a trial sample software In 
a function and validity limited version, which is operable 
by itself and which is to be offered for free. 

The passive function file 437 is to be provided in 
response to the user request, and used for a validity 
limit cancellation and a function addition (including a 
case of version updating) with respect to the already 
distributed core software 436. This passive function file 
437 is not operable by Itself, and can be set operable by 
being incorporated into the core software 436. The pas- 
sive function file 437 is a data file or a program file which 
is normally fee charged, distributed to the client terminal 
402 in the encrypted form, and stored in the encrypted 
form at the client terminal 402. 

Also, the core software 436 Is normally formed by a 
plurality of files and usually has a larger size, while the 
passive function file 437 usually has a relatively smaller 
size. 

Fig. 12 shows a partial configuration Ibr explaining 
the function of the core software in this second embodi- 
ment. 

This core software 436 is not completely operable 
even when it is installed into the client terminal 402. and 
further functions can be added to this core software 436 
by incorporating the deaypted passive function file 437 
into this core software 436. 

In other words, even when this software is executed 
by a person who has no right to decrypt this passive 
function file 437. not all the functions of the software can 
be realized. 

When the core software 436 is executed, the 
installed information storage unit 501 is searched 
through to check whether the passive function file 
related to this core software 436 is already installed or 
not. When the related passive function file is already 
installed, this encrypted passive function file is read out 
from the encrypted software storage unit 441. 
decrypted at a software decryption unit 436a by using 
the shared key 461 . and the resulting decrypted passive 
function file 437 is stored into the decrypted software 
loading unit 436b. If the shared key 461 cannot be 
obtained at this point, correct data cannot be stored into 
the decrypted software loading unit 436b. 

The core software 436 verifies that the passive 
function file 437 stored the decrypted software loading 
unit 436b is the con-ect data. Here, a method for realiz- 
ing this verification can be a method for checking 
whether the passive function file 437 stored in the 
decrypted software loading unit 436b is identical to data 



anticipated by the core software 435 or not (i.e.. whether 
it is correctly decrypted or not), or a method for execut- 
ing the passive function file 437 stored in the decrypted 
software loaiing unit 436b itself as a program, for exam- 
ple. 

The advantages of using this software product con- 
figuration for separately distributing the core software 
and the passive function file are as follows. 

Rrst, only a charged portion of the software can be 
sold as the passive function file. For example, the core 
software can be a word-processor without a printing 
function and a communication function, and the printing 
function and the communication function are to be sold 
as separate charged softwares. Using this scheme, the 
core software can be distributed for free through a freely 
accessible medium such as a CD-ROM or an electronic 
message board from which the core software can be 
acquired by anyone, and the charged portion can be 
purchased only when a user is satisfied with a trial use 
of the core software. 

In the conventional nnail order sales, there is a sys- 
tem for protecting a customer called a cooling off period 
during which a customer can return the purchased 
product for free of charge because the product cannot 
be checked In advance, but In a case of dealing with the 
software which is in an intangible form, it is impossible 
to return the once purchased software. In this regard, it 
is possible to protect the customer by offering the core 
software as a sample version for trial use by the con- 
sumer, without a need for any cooling off period. After 
the actual trial use, the customer can purchase the 
other charged functions (passive function file) only 
when the customer is satisfied with the trial use. In addi- 
tion, instead of providing one free portion and one 
charged portion, it is possible to offer more than one 
additional functions, so that the customer can purchase 
only the desired additional functions at appropriate 
price. In this manner, it is also possible to prevent an 
unfair trade practice to require the customer to purchase 
everything Including those functions which are actually 
unnecessary for that customer. 

Also, an amount of data involved in the encryption 
and decryption can be reduced in this application case. 
In general, the calculation for the encryption or decryp- 
tion takes a time in proportion to an amount of data 
involved, so that if a software in a very large size is sold 
by encrypting it one by one at a time of purchase, it 
would require a considerable amount of time for the pur- 
chase (downloading) and/or the execution (decryption). 
For this reason, a portion to be enaypted should be 
kept as small as possible. 

Also, the reduction of an amount of data implies 
that the communication line can be a thin one. In other 
words, the downloading takes time in general when a 
communication line between the store and the customer 
for purchasing the charged information is slow, but if the 
core software was already distributed by a CD-ROM or 
acquired through the other high speed network, it suf- 
fices to acquire a small passive function file alone, so 



15 



20 



25 



30 



35 



40 



45 



SO 



14 



27 



EP0 795 809A2 



28 



that the purchase does not take much time. 

Moreover, this software product configuration can 
also be utilized as a measure for preventing the illegal 
copy. Namely, at the client terminal 402, the shared key 
261 to be used in decrypting the passive function file 
437 Is stored in an encrypted form obtained by using the 
product ID 467. so that the decrypted passive function 
file 437 is present on a memory only while the core soft- 
ware 436 is executed. Consequently, even when all of 
the key file 452, the core software 436, and the 
encrypted passive function file 437 are copied, it is 
impossible to execute an illegally copied software 
unless the product ID 467 is also obtained. Moreover, it 
is also difficult to make an illegal copy of the software by 
analyzing the operation mechanism of the software, so 
that it actually becomes pointless to make an illegal 
copy by spending much effort and time. 

For example, when the software to be sold is in a 
form of a book, the software will be eventually converted 
into the character string data in a computer readable 
format on a memory, so that it is possible to steal such 
converted data from a memory rather easily. In such a 
case, the core software 436 can be set as a software for 
reading the book, which reads the individual software 
(book) offered as the passive function file 437 and dis- 
plays a content of the individual software on a screen. 
Then, by adopting a mechanism in which the core soft- 
ware 436 decrypts and displays the necessary data 
(encrypted data) whenever a need arises, it becomes 
quite difficult to read out all the book data (characters) 
together. 

In addition, the deaypted passive function file 437 
is going to be present on a memory only while the core 
software 436 is executed, so that when a procedure for 
the core software 436 to utilize the passive function file 
437 is made very tedious, it is possible to improve the 
safety because it would require a considerable amount 
of effort and time to break the encryption of the soft- 
ware. 

In general, a software to be sold through a network 
is often a software which requires rather frequent ver- 
sion updating or an information with only a temporal 
value (such as a weather forecast information), so that 
when the safety level of the software is made very high, 
it becomes much more economical to purchase the soft- 
ware legitimately by paying the proper price rather than 
spending much effort and time to produce illegal copies 
of the software. Consequently, when the safety level is 
made very high, it becomes pointless to commit the ille- 
gal act. and the fair distribution of the software will be 
promoted. 

Next, with reference to Fig. 13, the detailed 
processing procedure at a time of downloading a 
desired software from the server 401, i.e., the process- 
ing procedure of the download program function unit 
432, will be desaibed. 

First, the user activates the browser of the client ter- 
minal 402. for example, and makes an access to the 
sender 401 by manipulating the mouse and requests a 



desired software to the server 401 . At this point, the cli- 
ent terminal 402 obtains an information on the environ- 
ment of the client terminal 402 such as a type and a 
version of OS, a type of browser, etc.. and transmits this 

5 information to the server 401 as an automatic environ- 
ment judgement result. This autonnatic environment 
judgement result is provided as an option at a time of 
requesting the software. A function for obtaining and 
transmitting this information on the environment is usu- 

10 ally provided in the browser for general use (step S1). 
At the install list transmission function unit 415 of 
the server 401 which received this transmission 
request, an install list (a list describing which file should 
be installed how) corresponding to the software sped- 

15 fied by the user is read out from the install list storage 
unit 425 and transmitted to the client terminal 402 (step 
S2). 

At this point, the server 401 knows the environment 
of the client terminal 402 according to the automatic 

20 environment judgement result received from the client 
terminal 402 as an option, so that the sender 401 can 
change the install list to be transmitted to the client ter- 
minal 402 according to the environment of the client ter- 
minal 402, For example, for the client terminal 402 using 

25 a specific OS, the install list of softwares that can be 
operated by that specific OS will be transmitted. 

Rg. 14 shows an exemplary data configuration 
transmitted from the server 401 at this point, which gen- 
erally comprises a header portion and a data portion. 

30 The header portion contains an identification infor- 
mation 471 (Content-type: Application/ABC) such that 
the download program will be automatically activated 
when this identification information 471 is detected at 
tiie client terminal 402. (This setting is already made 

35 when the registration software function unit 431 installs 
the download program.) 

The data portion has an install list inserted therein 
in this example. As shown in Fig. 14, the install list is 
formed by the latest version of the download program 

40 (Download-version), an address information for the 
server 401 (URL, for example), and a plurality of com- 
nrands. 

The commands are used for notifying functions 
selected by the user*s clicking of the mouse to the 

45 download program. For example, there is an install com- 
mand (either for the core software or the passive func- 
tion file) as shown in Fig. 15. which describes which file 
should be installed how. A concrete example of such an 
install command is shown in Fig. 16. 

so The install command shown in Fig. 1 6 indicates that 
"Revision 3" of "dic2" function of "version V of the file 
name "MT" is required, and this file should be transmit- 
ted in three divided parts, where an amount of transmis- 
sion is 512 Kbytes for the first one and the second one. 

55 while it is 1 39 Kbytes for the third one, and a total capac- 
ity of a file obtained by concatenating and de-compress- 
ing these three parts is 7439 Kbytes. Using such an 
install command as shown in Fig. 15, it becomes possi- 
ble to download the software in divisions. Note that the 



15 



29 



EP0 795 809 A2 



30 



collective download can also be specified by setting "n = 
1 " In the division specification field of Fig. 1 5. 

The commands also includes a command for dis- 
playing a version updating information for the software 
purchased by the user. If a file specified in this com- 
mand is not installed, this command sets an execution 
of a subsequent install command as an error. This is 
used at a time of selling the passive function file, in 
order to confirm that the corresponding core software is 
already Installed and normally operating. 

Next, when the install list transmitted from the 
server 401 at the step S2 is received, the client terminal 
402 detects the identification information 471 contained 
in the header portion of Fig. 14 and activates the down- 
load program. Then, the latest version (Download-ver- 
sion) of the download program contained in the received 
install list is checked (step S3). If the latest version has 
been updated, the download of the download program 
in the latest version is requested to the server 401 (step 
S4}. In response, the server 401 reads out a file of the 
download program in the latest version from a pre- 
scribed software storage unit, and downloads this file 
into the client terminal 402 without encrypting this file 
(step S5). 

When a file of the download program in the latest 
version is received at the client terminal 402, the down- 
loading of this file is handled differently from the down- 
loading of the other files. Namely, the currently executed 
download program is not to be ovenvritten. and when 
the cun-ently executed download program is installed 
under a name of "download 1", for example, the down- 
load program in the latest version is installed under a 
name of "download2", and a setting file for realizing the 
automatic execution of the download program Is also 
rewritten. Then, data processed by the currently exe- 
cuted download program "download r are given to the 
download program in the latest version "download2'' as 
they are. and the download program in the latest version 
is activated. Consequently, after the version updating, 
there are always two program files "downloadr and 
"download2". 

The reason for handling this version updating to the 
download program in the latest version differently from 
the downloading of the other files is that the processing 
contents of the currently executed download program 
are not going to be renewed even when a new file is 
overwritten onto the currently executed download pro- 
gram. 

Next, at the client terminal 402. the version informa- 
tion for the files (core software, passive function file) 
constituting the software specified by the user which is 
described in the install list is compared with the version 
information for the file registered in the installed infor- 
mation storage unit 501 . so as to check whether there is 
any file whose version has been updated, or whether 
there is any new additional function file (passive func- 
tion file) in the install list. When such a file exists, a 
download request with a prescribed header information 
for the necessary file attached thereto is transmitted to 



the server 401 (step S6). 

Here, the download request contains an informa- 
tion on the version of the currently installed file, for 
example. Also, the header information includes an infbr- 

5 mation (such as the purchase key for example) for indi- 
cating that the user registration is already completed. 

When the server 401 receives the download 
request from the client terminal 402, and recognizes 
that this user is an already registered user according to 

10 the header information of the download request, the 
processing for the received download request is exe- 
cuted, and the downloading of the specified file is car- 
ried out in a format shown in Fig. 1 7 (step S7). 

In Rg. 17. a type of data to be transmitted is 

15 described in a "transmission format" field. For example, 
"0" indicates a collective transmission of an entire file, 
"r indicates a collective transmission of a remainder of 
data. "2" indicates a transmission of an entire file in divi- 
sions, and "3" indicates a transmission of a remainder of 

20 data in divisions. 

Also, a file to be inserted into a "data" field may be 
compressed by a prescribed compression program. In 
such a case, the de-compression program may be con- 
tained in the download program or may be provided as 

25 an external program to be read separately 

Also, a "data size" field indicates a size of data in 
the "data" field, a "MASK" field indicates a mask to be 
applied to the shared key, a "check sum" field indicates 
a check sum with respect to the data (non-encrypted) in 

30 the "data" field, and a "hash value" field indicates a hash 
value obtained by applying the hash function on all of 
the data size, data, check sum, and MASK field con- 
tents. Here, the hash value is used so that the download 
program can detect an error when the hash value is not 

35 correct. Note that, when the "MASK" field has "0", it 
implies that the file in the "data" field of this format is not 
to be encrypted. 

At the server 401 , after the file is transmitted, if the 
transmitted file is a fee charged one, the credit card 

40 number of this user is obtained by referring to the per- 
sonal information file storage unit 424 by using the pur- 
chase key as a search key and the credibility inquiry to 
the credit card company and the charging processing 
are candled out according to the obtained credit card 

45 number. 

Also, at a time of downloading, a part which is 
required to be encrypted is encrypted by the pre-regis- 
tered shared key 

Here, if the download fails in a middle (for a reason 
50 such as a disconnection of a communication line, for 
instance) while the charging is successfully made, this 
download failure can be simply ignored. It suffices to 
carry out the downloading again without carrying out the 
charging processing when this user makes the same 
55 purchase operation again. 

Now. the various effects of the software distribution 
system in ttiis second embodiment as described above 
will be summarized. 
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(1) Automatic install function: 

The autonnatic environment judgement result 
obtained at the client terminal 402 is transmitted to the 
server 401, and the server 401 distributes the suitable 
software according to this automatic environment 
judgement result. Then, at the client terminal 402, the 
downloaded file is installed immediately when it Is 
received, by the installer provided in the download pro- 
gram. In this manner, the Install can be realized easily 
and surely even when the user does not have a thor- 
ough knowledge of the personal computer. 

In addition, at a time of automatically Installing the 
file downloaded from the server 401 . the download pro- 
gram at the client terminal 402 executes the processing 
by recognizing the identification information set at a 
time of the user registration, so that there is no danger 
for introducing a computer virus. 

(2) Automatic charging function: 

An information such as a credit card number is reg- 
istered in the server 401 at a time of the user registra- 
tion, so that at a time of purchasing the software, it 
suffices to transmit only a purchase request for a 
desired software. Then, by utilizing the on-line credibility 
inquiry using the registered credit card number, the 
charging is immediately carried out at the server 401. 
Consequently, the user is only required to make some 
mouse clicking in purchasing the software, so that this 
scheme is suitable for the sales of cheap softwares. In 
addition, there is no need to enter the credit card 
number at every occasion of purchase, so that the 
safety level is improved. 

(3) Automatic version updating function: 

The download program at the client terminal 402 
checks whether a version of a file already installed into 
that terminal has been updated or not by referring to the 
install list transmitted from the server 401. and a result 
of this checking is presented to the user. According to 
this checking result, the user can easily makes the 
download request for the necessary file by simply 
manipulating the mouse. In addition, only the necessary 
portion is downloaded from the server 401. so that an 
amount of communication can be reduced and the com- 
munication line cost can be saved. 

(4) Trial use of software: 

The user is allowed to make a trial use of a free trial 
sample version (core software) of the software first, and 
then the user purchases a fee charged software portion 
(passive function file] for enabling the regular operation 
which is to be incorporated into the core software. Con- 
sequently, a trouble or dissatisfaction regarding the pur- 
chased software product can be eliminated, so that this 
scheme Is suitable for the sales of electronic information 



which is not returnable. 

(5) Illegal copy prevention function: 

5 The fee charged software portion (passive function 
file) is stored in an encrypted form at a time of being 
downloaded from the server 401 and installed into the 
client terminal 402, and this passive function file is 
decrypted by a decryption and incorporation function of 

10 the core software at a time of each software activation in 
order to convert the software into an executable form. 
Here, tiie shared key uniquely assigned to the user is 
used in the decryption, and this shared key is stored in 
an encrypted form obtained by using tiie product ID 

15 which is uniquely defined at the client terminal 402. 
Consequentiy, even when all of tiie key file 452, the core 
software 436. and the encrypted passive function file 
437 are illegally copied, it is impossible to execute the 
illegally copied software unless tiie product ID is also 

20 obtained. 

(6) Version updating for download program: 

The download program at the client terminal 402 
25 checks a version information for the download program 
which is described in the install list transmitted from tiie 
server 401 . and automatically requests tiie download of 
tiie download program in the latest version to the server 
401 if tiie version has been updated, In tiiis manner, tiie 
30 version updating of the download program can be real- 
ized easily, and consequently an addition of types of 
commands to be described in tiie install list becomes 
easier. 

35 (7) Software downloading in divisions: 

In a case of downloading tiie software in a large 
size, the server 401 can try to transmit such a software 
in divisions. Namely, tiie downloading in divisions is 

40 commanded by the install command described in tiie 
install list in such a case. In tiiis manner, when tiie 
downloading fails as a trouble occurs in the communica- 
tion line between the server 401 and tiie client terminal 
402. a procedure to reti-y the downloading can be made 

45 simpler. 

Note tiiat. in the above description, it is assumed 
tiiat tiie passive function portion of the software is to be 
sold as a fee charged software, but this second embod- 
iment is not necessarily limited to this case, and tiie 

so passive function portion can be provided as a free addi- 
tional function to the active function portion. In such a 
case, it is not absolutely necessary to can-y out tiie 
encryption of tiie passive function portion. 

It is to be noted that, in tiie present invention 

55 described above, the encryption/decryption by using tiie 
shared key is not necessarily limited to tiie enayp- 
tion/decryption using the shared key as enayp- 
tion/decryptlon key. For example, it is possible to 
provide a table of con^espondence between the shared 
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key and a separate key for enayption/decryption. where 
the corresporxlence is guaranteed in some suitable 
manner, and carry out the actual enayption/decryption 
by using this separate key (which is related to the 
shared key) instead of using the shared key itself. This 
meaning of the encryption/decryption by using the 
shared key is intended in the appended claims as well, 
so that the encryption/decryption by using the shared 
key should be construed to cover not only a case of car- 
rying out the actual encryption/deayption using the 
shared key itself as encryption/decryption key, but also 
a case of carrying out the actual encryption/decryption 
using a key data related to the shared key as encryp- 
tion/decryption key 

It is also to be noted that, besides those already 
mentioned above, many modifications and variations of 
the above embodiments may be made without depart- 
ing from the novel and advantageous features of the 
present invention. Accordingly all such modifications 
and variations are intended to be included within the 
scope of the appended claims. 

Claims 

1. A method for utilizing a software, comprising the 
steps of: 

storing a shared key shared between a soft- 
ware provider and a user, the shared key hav- 
ing a guaranteed correspondence with an ID 
information regarding a payment of a software 
fee by the user; 

requesting a desired software from the user to 
the software provider, and receiving the 
desired software in an encrypted form from the 
software provider; 

decrypting the desired software received from 

the software provider by using the shared key 

stored at the storing step; and 

utilizing the desired software in a decrypted 

form. 

2. The method of claim 1 , wherein the guaranteed cor- 
respondence between the shared key and the ID 
information is established by the steps of: 

generating the shared key at a user side; 
encrypting the shared key at the user side by 
using a public key corresponding to a secret 
key of the software provider and sending the 
shared key in an encrypted form from the user 
side to the software provider; and 
encrypting the ID information at the user side 
by using the shared key and sending tiie ID 
information in an encrypted form from tiie user 
side to the software provider. 

3. The method of claim 1 , wherein the guaranteed cor- 
respondence between the shared key and the ID 



information is established by the steps of: 

generating tiie shared key at a user side; and 
encrypting the shared key and the ID Informa- 
5 tion at the user side by using a public key cor- 

responding to a secret key of the software 
provider and sending the shared key and tiie ID 
information in an encrypted form from tiie user 
side to the software provider. 

10 

4. The method of claim 1, wherein tiie storing step 
stores tiie shared key by obtaining an auxiliary 
information regarding a software utilization, 
encrypting the shared key by using tiie auxiliary 
15 information, and storing the shared key in an 
encrypted form, and 

the decrypting step decrypts the desired soft- 
ware by obtaining the auxiliary information, 
20 decrypting tiie shared key in an encrypted form 

by using the auxiliary information, and decrypt- 
ing the desired software by using the shared 
key in a decrypted form. 

25 5. The method of daim 1. wherein tiie utilizing step 
utilizes the desired software in executing another 
already provided software. 

6. A software distribution system in which a desired 
30 software is provided in an encrypted form from a 
software provider to a user, comprising: 

shared key storage units provided at both a 
software provider side and a user side, for stor- 
35 ing a shared key shared between the software 

provider and tiie user, tiie shared key having a 
guaranteed correspondence with an ID infor- 
mation regarding a payment of a software fee 
by tiie user; 

40 a request transmission unit provided at the 

user side, for transmitting a request for tiie 
desired software to tiie software provider side; 
a software encryption unit provided at tiie soft- 
ware provider side, for encrypting the desired 

45 software by using tiie shared key stored in tiie 

shared key storage unit on the software pro- 
vider side; 

an encrypted software transmission unit pro- 
vided at the software provider side, for trans- 

50 mitting the desired software in an encrypted 

form to the user skle; and 
a software decryption unit provided at the user 
side, for receiving the desired software in an 
encrypted form from tiie software provider. 

55 decrypting tiie desired software received from 

the software provider by using the shared key 
stored in the shared key storage unit on tiie 
user side, so as to obtain the desired software 
in a decrypted form tiiat can be utilized at tiie 
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user side. 

7. The system of claim 1 , further comprising: 

a request inspection unit provided at the soft- s 
ware provider side, for inspecting whether the 
request for the desired software is proper or not 
by using the shared key stored in the shared 
key storage unit on the software provider side; 
and 10 
a software transmission command unit pro- 
vided at the software provider side, for com- 
manding an execution of an encryption by the 
software encryption unit and a transmission by 
the encrypted software transmission unit when 
the request inspection unit judges that the 
request for the desired software is proper. 

8. The system of claim 6. further comprising: 

a shared key generation unit provided at the 
user side, for generating the shared key; 
a shared key encryption unit provided at the 
user side, for encrypting the shared key by 
using a public key corresponding to a secret 
key of the software provider and sending the 
shared key in an encrypted form to the soft- 
ware provider; and 

an ID information encryption unit provided at 
the user side, for encrypting the ID information 
by using the shared key and sending the ID 
information in an encrypted form to the soft- 
ware provider, so as to establish the guaran- 
teed correspondence between the shared key 
and the ID information. 

9. The system of claim 6, further comprising: 

a shared key generation unit provided at the 
user side, for generating the shared key; and 
a shared key and ID information encryption unit 
provided at the user side, for encrypting the 
shared key and the ID information by using a 
public key corresponding to a secret key of the 
software provider and sending the shared key 
and the ID information in an encrypted form to 
the software provider, so as to establish the 
guaranteed correspondence between the 
shared key and the ID information. 

1 0. The system of claim 6, wherein the shared key stor- 
age unit on the user side stores the shared key by 
obtaining an auxiliary information regarding a soft- 
ware utilization, enaypting the shared key by using 
the auxiliary information, and storing the shared key 
in an encrypted form, and 

the software decryption unit decrypts the 
desired software by obtaining the auxiliary 



information, decrypting the shared key in an 
encrypted form by using the auxiliary informa- 
tion, and decrypting tiie desired software by 
using tiie shared key in a decrypted form. 

11. A software distribution system in which a desired 
software is provided from a software provider to a 
user through a network, comprising: 

a client terminal on a user side, which is con- 
nected with a server on a software provider 
side tiirough the networK and including: 

a registration unit for registering a user 
charging information and a shared key 
shared between tiie software provider and 
the user into the server; 
a request unit for sending a request for a 
desired software to the server; and 
an install unit for installing each software 
downloaded from the server in response to 
the request sent by tiie request unit; and 

a server on tiie software provider side, includ- 
ing: 

a charging processing unit for carrying out 
a charging processing according to tiie 
user charging information registered by the 
registration unit, when the desired soft- 
ware requested by the request is a fee 
charged software; and 
a download unit for downloading a soft- 
ware in response to the request sent by the 
request unit, tiie software to be down- 
loaded being encrypted by using tiie 
shared key registered by tiie registration 
unit when tiie software to be downloaded 
is required to be encrypted. 

1 2. The system of claim 1 1 . wherein each software pro- 
vided by the software provider comprises an active 
function portion which is independentiy operable 
and which is provided from tiie server for free at a 
time of a software purchase by the user, and a pas- 
sive function portion which becomes operable by 
being incorporated into the active function portion 
and which is fee charged, and 

the charging processing unit carries out the 
charging processing when the request sent by 
the request unit is requesting tiie passive func- 
tion portion. 

1 3. The system of claim 1 1 , wherein each software pro- 
vided by the software provider comprises an active 
function portion whicti is independentiy operable, 
and a passive function portion which becomes 
operable by being incorporated into the active func- 
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tion portion, 

the downloading unit downloads the passive 
function portion in an encrypted form obtained 
by using the shared key; and s 
the install unit installs the passive function por- 
tion and the active function portion so that, the 
passive functon portion installed by the install 
unit is stored in an encrypted form, and the 
active function portion installed by the install 10 
unit decrypts the passive function portion in an 
encrypted form by using the shared key and 
incorporates the passive function form In a 
decrypted form, each time the active function 
portion is activated at the client terminal. is 

14. The system of daim 11, wherein the client terminal 
further includes: 

a key management unit for generating the 20 
shared key. encrypting the shared key by using 
a code information uniquely defined for the cli- 
ent terminal, and storing the shared key in an 
encrypted form. 

25 

15. The system of claim 1 1 , wherein the download unit 
downloads a software which is selected according 
to an environment judgement result for the client 
t^minal notified from the client terminal to the 
server in advance. 30 

16. The system of claim 11 , wherein the server further 
includes: 

a list providing unit for providing the user with a 35 
list information containing a version information 
for each software that can be provided to the 
user, in response to a request for the list infor- 
mation from the client terminal, so that the 
request sent by the request unit requests the 40 
desired software selected according to the list 
information. 
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